Sorry, my first thought here is, "no, that's what "MAV_CMD_DO_RETURN_PATH_START is for".

Sorry, my first thought here is, "no, that's what "MAV_CMD_DO_RETURN_PATH_START is for".

@peterbarker No need to be sorry, this stuff should be discussed before being invented (however this ends up).

As it turns out MAV_CMD_DO_RETURN_PATH_START doesn't have the right semantics

• they need the radius because it is FW.
• They may need the heading and xtrack (unknown to me)
• The command needs to be associated with a rally point, not a land_start - though I guess we could change the text.

Either way the fundamental discussion I want to have here is not so much "is the right way" as "is this non-compliant or just a use of the standard that we haven't thought of", as that defines how we manage this kind of thing going forward. I think this is use of the standard we haven't thought of.

Sorry, my first thought here is, "no, that's what "MAV_CMD_DO_RETURN_PATH_START is for".

@peterbarker No need to be sorry, this stuff should be discussed before being invented (however this ends up).

As it turns out MAV_CMD_DO_RETURN_PATH_START doesn't have the right semantics

* they need the radius because it is FW.

* They may need the heading and xtrack (unknown to me)

* The command needs to be associated with a rally point, not a land_start - though I guess we could change the text.

Not sure what you mean by "need the radius" here. You can put whatever mission commands you like after DO_RETURN_PATH_START with whatever parameters you'd like in them.

Reading the topic of that PX4 pull request - that's pretty much exactly what DO_RETURN_PATH_START is for!

Either way the fundamental discussion I want to have here is not so much "is the right way" as "is this non-compliant or just a use of the standard that we haven't thought of", as that defines how we manage this kind of thing going forward. I think this is use of the standard we haven't thought of.

AFAICS this is definitely in the, "that's absolutely the wrong way to do and would require rewriting a whole bunch of GCS code to allow for planning this out", whereas adding extra mission items - DO_RETURN_PATH_START, for example isn't a problem.

IMO rally points are not "mini missions" and shouldn't be used as such.

Merging PRs that stretch what you can do with rally points like this and then saying the standard has to be modified to accommodate them is... let's say "rude".

Unless I'm missing something with that feature, I very much doubt ArduPilot would ever implement it as it would seem to be entirely redundant. Something like QGC will need an option bit to see if the vehicle has the sort of behaviour it is after. This is not a "standard".

Please check to see if DO_RETURN_PATH_START could be used instead. It works very well.

@peterbarker Sorry, I think I must be putting the use case poorly.

DO_RETURN_PATH_START is used to identify a safe path to join a mission path, so that you can safetly follow it to a mission-based landing pattern used as a destination for a return action. It's very clever, but it assumes that we want to do a mission return path, or even that we have a mission. We don't in this case.

The intent is not to make a mini-mission.
The use case here is VTOL fixed-wing rally point return. The rally point isn't in the mission and might be used outside of a mission. In all implementations prior to what PX4 is doing here you had just rally points and the flight stacks pick the closest of the rally points or home.

The idea is that you can define an approach to the rally point by specifying a point near it that the vehicle will go to first, so that we know there is a safe vector to that point.
More specifically, we define a number of points that the vehicle might go to, and let the flight stack pick the one that makes sense for where the rally point was invoked [PX4 chooses the best one based on wind direction]

That's a solid use case. I don't see how you can do that in a rally point definition "flexibly" without a way to specify a waypoint associated with the rally point.

TL;DR. What is clear right now is that you have strong objections to this being standard, and therefore it can't be considered standard. I'll add this as as a non-standard implementation thingy and we should discuss if there are better ways that aren't such colossal hacks.

You're right that using rally points in this way is a hack.
In much the same way that using mission landing patterns in missions as an RTL path is a hack, and things like MAV_CMD_DO_RETURN_PATH_START are further hacks to make them work better.

We use them because its the hammer we have, not because using mission landings as the return path are the best solution.
Maybe we should propose a new plan type for landing points that is indeed mini missions. This could then represent mission landing points and/or rally points with paths.
A flight stack could then reasonably plot the different allowed landing points, because the design could be explicit.

I'd prefer we did that as it would be designed.

Hey @peterbarker, @hamishwillee

There is a slight misunderstanding. VTOL land approaches were merged here PX4/PX4-Autopilot#21049 3 years ago, it's not a new behavior being pushed to the standard. This PR: PX4/PX4-Autopilot#27004 just fixed how the approaches were computed and documented the behavior (because I did not know that those existed).

You can put whatever mission commands you like after DO_RETURN_PATH_START with whatever parameters you'd like in them.

@peterbarker the way I understand the docs (correct me if I'm wrong), the drone will not necessarily fly to the DO_RETURN_PATH_START location and perform that command. E.g. in the image below from https://ardupilot.org/plane/docs/common-do-return-path-start.html if the drone is between waypoints 4 and 7, it will not fly back to the DO_RETURN_PATH_START as it would crash into the trees which defies the purpose of that DO_RETURN_PATH_START.

If so, DO_RETURN_PATH_START cannot solve what the VTOL approaches solve which is having different locations not necessarily on the route to perform a specifc VTOL descent based on wind before landing.

There is a slight misunderstanding. VTOL land approaches were merged here PX4/PX4-Autopilot#21049 3 years ago, it's not a new behavior being pushed to the standard. This PR: PX4/PX4-Autopilot#27004 just fixed how the approaches were computed and documented the behavior (because I did not know that those existed).

Cool cool. Documentation is good.

You can put whatever mission commands you like after DO_RETURN_PATH_START with whatever parameters you'd like in them.

@peterbarker the way I understand the docs (correct me if I'm wrong), the drone will not necessarily fly to the DO_RETURN_PATH_START location and perform that command. E.g. in the image below from https://ardupilot.org/plane/docs/common-do-return-path-start.html if the drone is between waypoints 4 and 7, it will not fly back to the DO_RETURN_PATH_START as it would crash into the trees which defies the purpose of that DO_RETURN_PATH_START.

Right, the vehicle only treats the DO_RETURN_PATH_START location's location as a hint as to which one to use. ArduPilot solely uses geographic proximity to select a sequence - it never flies there. Any items between the return path start and do_land_start it is associated with are considered valid join points to that path.

If so, DO_RETURN_PATH_START cannot solve what the VTOL approaches solve which is having different locations not necessarily on the route to perform a specifc VTOL descent based on wind before landing.

I guess DO_LAND_START might be more-equivalent to what PX4 appears to be using extra-items-in-rally-protocol for? It works the same in terms of location - it's used for selection but not as a destination. If I'm thinking right if you were to drop a DO_LAND_START exactly over a DO_LAND - and have your approach plan as waypoints in between - you end up with what the rally thing does.

This is the bit being violated, BTW:

      <entry value="2" name="MAV_MISSION_TYPE_RALLY">
        <description>Specifies the rally points for the vehicle. Rally points are alternative RTL points. Items are MAV_CMD_NAV_RALLY_POINT rally point items.</description>
      </entry>

This got discussed in 20260617-Dev-Meeting.

@JonasPerolini Understand this is not your "fault", but whether it is three years or 30 things aren't standard unless they are an agreed part of the standard. Right now this is a hack.

@peterbarker That said, we all feel using rally points for landing behaviours makes sense. There is no reason these could not be other kinds of landing patterns too - such as fixed-wing landing patterns. To progress this we would need some consideration of how this might be extended in future so that we can ensure whatever approach is used is agreed and documented.

Keep the mission planning for.... missions.

Precisely my point. Anything that doesn't depend on a mission doesn't automatically belong in the mission plan - any more than geofencesor rally points do. This is behaviour that doesn't and shouldn't rely on a mission.

I can see that it is very tempting to use "the hammer you have" for handling sequences, but that doesn't mean it is the right thing to do. By way of evidence, this was already implemented, and the world did not end.

This isn't a documentation issue - the approach of using missions for this kind of thing is wrong. We'll have to agree to disagree until you're convinced.